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SECURE DIGITAL CONTENT DELIVERY SYSTEM AND METHOD 
OVER A BROADCAST NETWORK 

FIELD OF THE INVENTION 
5 The present invention relates to a system and a method for digital content delivery, and 

in particular, to such a system and method in which the digital content is broadcast and/or 
multicast securely through a broadcast network, such as a packet-based network and/or IP 
network. 

10 BACKGROUND OF THE INVENTION 

Digital media content can easily and efficiently be delivered through any type of suitable 
network, although typically such digital content has been delivered through cable and/or satellite 
networks as broadcast digital content- However, in order for digital content to be fully 
effectively delivered to users, the basis for secure delivery needs to be provided. In particular, if 

1 5 payment is required, the digital content should be secure against theft, such that only authorized 
users can retrieve and display the digital content. At the same time, the content also should be 
delivered in an efficient manner, for example by enabling the secure delivery to be performed 
efficiently, without hindering or otherwise reducing the performance of the delivery mechanism 
itself, such as broadcast and/or multicast, for example. 

20 One attempt to provide such effective mechanisms is described in US Patent Nos. 

5,282,249 and 5,481,609, both to Cohen et al., which are hereby incorporated by reference as if 
fully set forth herein. The disclosed system enables a signal containing media content to be 
broadcast widely, yet only to be played back or otherwise displayed by authorized users. This 
signal could contain a television program for example. The signal is scrambled, such that the 

25 authorized users are able to unscramble the signal and play back or otherwise display the media 
content only with the proper security device, such as a smart card for example. Thus, widely 
received media content is still protected from access by unauthorized users. 

Scrambled television data streams described in the Cohen et al patents comprise both 
scrambled data representing television signals and coded control messages, also known as ECMs 

30 (Entitlement Control Messages). The ECMs of Cohen et al comprise, in a coded form, data 

necessary for generating a control word (CW) which may be used to descramble the scrambled 
" data representing television signals. An ECM is also termed a control word packet or CWP. 
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Data necessary for generating a control word is known in the background art to take 
many different forms and may include, in general, at least any of the following: a control word; 
an encrypted control word packet which is intended to be decrypted before use; and a seed to a 
generating function such as, for example, a one-way function which generates the control word 
5 upon input of the seed. Throughout the present specification and claims the terms "control word 
generating information" and "CW generating information" are used interchangeably to designate 
data necessary for generating a control word in any appropriate form, as described above. 

Another attempted solution is described in published European Patent Application No. 
EP 0858184 and in corresponding US Patent 6,178,242, which disclose a digital recording 

1 0 protection system and which are hereby incorporated by reference as if fully set forth herein. 
The disclosed system enables the digital content to be sent in a digitally scrambled format, such 
that the digital content cannot be read and/or displayed without a key. The key is obtained from 
a control message, which is only sent to authorized users. Preferably, the key is obtained from 
coded information contained within the Entitlement Control Message, or ECM, for generating a 

1 5 control word associated with the ECM. Thus, only authorized users are able to correctly read 
and/or display the digital content. 

In addition, the system and method described in European Patent Application No. EP 
0858 1 84 enable the authorized user to record and playback or otherwise display the digital 
content, while preventing the user from producing and distributing multiple playable copies of 

20 the digital content to other, non-authorized users. Therefore, the authorized user is able to fully 
use and enjoy the digital content, while the content itself is still protected from unauthorized use. 

As described in European Patent Application No. EP 0858184, and as shown in 
background art Figure 1 taken from this Application, such a system includes a media device 100, 
such as a television set, for playing the digital content, such as a television program for example. 

25 Media device 100 is connected to an integrated receiver-decoder (IRD) 110, for receiving and 
decoding the digitally scrambled digital content. The system also features a removable security 
element 120, such as a smart card for example, for providing control words for unscrambling, or 
otherwise rendering into a clear format, the digitally scrambled digital content by IRD 110. In 
addition, the system features a digital VCR 130 for communicating with media device 100 and 

30 IRD 1 10. Digital VCR 130 is able to record the digital content for later playback and/or display 
by media device 100. 

IRD 110 receives digitally scrambled digital content which features a plurality of ECMs, 
each of which is associated with, and is typically followed by, a digitally scrambled digital data 
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segment, containing the actual digital content. Each ECM includes coded information which can 
be used to generate a control word for unscrambling the associated digitally scrambled digital 
data segment. Typically, removable security element 120 generates the control word. IRD 110 
is then able to unscramble the digitally scrambled digital content, for example for being played 
5 by media device 100. 

Background art Figure 2, also taken from European Patent Application No. EP 0858184, 
is a flow diagram illustrating the production of the digitally scrambled digital content. As 
shown, the digitally scrambled digital content is produced as an SDDS (digitally scrambled 
digital data stream) 140, featuring a plurality of ECMs such as an nth ECM 145, and a plurality 

1 0 of associated SDSEGs such as an nth SDSEG (digitally scrambled digital data segment) 150 
which is associated with nth ECM 145. IRD 110 of Figure 1, in cooperation with removable 
security element 120, is able to use SDDS 140 in order to form a recording SDDS 165. 
Recording SDDS 165 is produced with the addition of a TECM (transformed ECM) key, which 
is permanently associated with the system of Figure 1, even if removable security element 120 is 

1 5 changed, replaced or exchanged, for example. This TECM key is used to make a plurality of 
TECMs, shown as nth TECM 175, from the control words of the ECMs. Thus, a system which 
did not feature the correct TECM key could not unscramble the recording SDDS 165 for playing 
back or otherwise displaying the digital content, while the authorized user is always able to play 
back or otherwise display the recorded digital content as long as the TECM key is available. 

20 All of these background art references describe mechanisms for the secure delivery of 

content which are quite useful for such networks as cable and/or satellite networks. However, 
these references are less useful for packet-based networks, such as the Internet for example, as 
well as for other types of IP networks. Packet-based networks are typically not dedicated 
networks for the delivery of particular types of digital media content. Certainly, many different 

25 types of content are delivered through the Internet. Furthermore, the Internet is an inherently 

open, insecure conduit for digital content, as it is widely accessible. The general accessibility of 
the Internet is also quite useful, since digital media content could be delivered to many different 
users, internationally, easily and at relatively low cost. Unfortunately, the above-referenced 
background art references do not teach or suggest a mechanism for secure delivery of digital 

30 media content through a packet-based network, particularly for selected, targeted digital media 
content. 

Furthermore, encryption for media content which is transmitted according to such 
formats and standards as MPEG (Motion Picture Expert Group) is handled at the PID level, such 
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that only 1 3 bits of information are provided, and such that decryption and re-encryption of the 
data would be required when transmitted across networks. Such a small amount of information 
is not sufficient for both encrypting the digital media content and for identifying those devices 
which are permitted to decrypt and access the content. The further requirement for 
5 encryption/decryption when crossing networks is also a disadvantage, since encryption of data 
which is transmitted according to IP protocols provides an "end-to-end" solution, such that the 
encrypted data is transmitted in its encrypted format to the end device or client. By contrast, 
PID is a data link protocol only, and as such, any encrypted data which is transmitted must be 
decrypted and re-encrypted at each segment of the transmission path, such that the encrypted 

1 0 data cannot be transmitted directly to the end device or client in its encrypted format. 

Currently, security for the transmission of content over packet-based networks is handled 
through one-to-one key exchange mechanisms, in which a central server sends a key 
individually to each end user computer. Clearly, sending such a key separately to each such 
computer is inefficient, as it requires extensive bandwidth. Furthermore, the management of 

1 5 such keys is also difficult, although a number of attempted solutions have been proposed. 

For example, EPSEC (Internet security framework) was initially developed as a 
framework for unicast protocols, which was also intended for use for multicast transmission as 
an additional feature (but which was not specifically designed for multicast transmissions). 
However, some of the elements that can be useful in a unicast environment become problematic 

20 when extended to multicast situations. A case in point is key based security systems and their 
required infrastructure. 

There are two main areas for classic key management in a multicast environment: 
initializing a multicast group with a common key and rekeying (or updating) the multicast group. 
For example, public key systems require a mechanism for obtaining the public keys necessary. A 

25 server and request model per session is notably insecure, e.g. imposter, man-in-the-middle, etc. 
If a client-server model is to be used, then third party authentication and certification is also 
necessary, for example according to the X.509 standard. This standard allows for certification 
hierarchy, and traversal of trusted paths; however, it is a slow and traffic heavy distribution 
method. 

30 Cryptographic techniques have been proposed in order to increase the security of key 

distribution, by encrypting the keys before they are sent. Unfortunately, a basic problem with 
using cryptographic techniques for key distribution is that each user must be authenticated to 
receive a key. 
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In general, standard group key management schemes establish and manage a common 
key for all members of a group. These management schemes are used for encryption standards 
and group authentication. A particular problem in this area is related to key revocation methods, 
as these models tend to work with largely static key possession, since updating with the 
5 distribution methods available tends to be bandwidth expensive and time consuming. Examples 
of key management protocols are described with regard to United Kingdom Patent No. GB 
2353682 and US Patent Application No. 09/502,867, both of which are hereby incorporated by 
reference as if fully set forth herein. 

One example of a significant Group Key Management proposal is the GKMP protocol, 

1 0 which uses symmetric keys for all members of the group. This mechanism features a dedicated 
Group Controller (GC) whose responsibility is managing the group keys. The GC generates 
group keys in a joint operation with a selected group member. It then communicates with each 
member separately, validating permissions and sending it a group key, which is encrypted using 
a shared key (between that member and the GC). This method has very obvious and severe 

1 5 scaling difficulties. 

The Scalable Multicast Key Distribution protocol uses Core-Based Tree routing protocol 
and provides a secure join to a group tree in a scalable method. In such a tree, the routers know 
the identities of their tree neighbors, and starting from the core which serves as a GC (for 
generating group session keys and key distribution keys) and working outwards, each router is 

20 delegated the ability to authenticate joining members and provide them with the group key. This 
method is scalable, however it is tied to a specific routing protocol, and combines routing with 
security, such that each router must be fully trusted since it has the same keys as the GC. 

In MKMP (Multicast Key Management Protocol), the initial Group Key Manager 
(GKM) delegates key distribution authority dynamically. The GKM generates a group key and 

25 then sends a multicast message soliciting members to whom it can delegate the distribution 

authority for the rest of the group members. A message containing keys and access lists is sent to 
and decrypted by those solicited members, who will then operate as GKMs in their own right. 
This method allows for a dynamic adaptable on-line group topology. Since MKMP uses a single 
key for the total group it avoids multiple (hop-by-hop) decryption/re-encryption of payload. 

30 lolus deals with scalability issues by using a "secure distribution tree", wherein the 

multicast group is divided into a hierarchical set of subgroups. There is a Group Security 
Controller (GSC) at the top level and Group Security Intermediaries (GSIs) for managing the 
subgroups. Each subgroup has its own sub-key, chosen by the GSI. The GSI knows the keys to 
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the subgroup and the next higher group and translates messages between the levels. This models 
suffers from built in latency, during decryption and re-encryption and has difficulties dealing 
with untrusted GSIs. 

In general, GKMP systems which rely on a single group controller still have difficulty 
5 scaling to large systems and are burdened by the 1 single point of failure' attribute. Single point 
of failure in this instance also reflects in the security realm. Where, in some of the models above, 
more than one GC is used, the compromise of one such GC usually means a compromise of the 
other GCs as well. Furthermore, all of these protocols suffer from drawbacks in the area of 
compromise recovery and/or revocations of membership. 

1 0 Various methods have been discussed in the literature in order to improve group key 

management systems, for example by using groups of members as controllers and cluster 
architectures. Hardjono, et al ("Secure IP Multicast: Problem areas, Framework, and Building 
Blocks Internet Research Task Force, draft-irtf-smug-framework-OLtxt September 2000; for 
other references, see the list at the end of this section) suggest a further extension of the Iolus 

1 5 tree distribution model, and other extensions/proposed solutions have also been suggested. 

In 'Key management for Multicast: Issues and Architecture' (see full reference below), a 
hierarchical tree approach is proposed in order limit the number of transmissions (key 
exchanges) and storage (of keys) required. Although more efficient than other variations, the 
basic key distribution principles are still enforced and are still subject to the same arguments 

20 previously cited against standard key distribution models. 

The above problems become even more complex with regard to key revocation. In order 
to prevent new group members from accessing older data or leaving members from accessing 
new data, a group controller has to change the multicast group key whenever membership in the 
group changes. Adding a new member either from a central GC or from one of the distributed 

25 models is fairly straight forward and efficient, i.e. using a one to one unicast model. However 
revoking membership rights in the standard group key protocols becomes very problematic, 
because the leaving member already has the group key. 

The approach taken by many key management protocols (GKMP A, SMKD, MKMP) to 
remove members is to generate a new group key, and to send it independently to each of the 

30 remaining group members, usually using secret keys which are shared between each of the 
members and the GC. In this scenario, a new multicast group is created. But the scaling 
problems here are significant, as are the timing issues, i.e. how to make the new key available in 
time to access the new data, and how to manage cases where it does not. In particular, the group 
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is not operational during the recovery process once the old key has been declared to be invalid, 
such that recovery/revocation processes are inefficient and may even prevent the legitimate 
members from receiving data and/or other services. Timing issues are less significant for the 
initial creation of the group, since members may be selected and may receive the key(s) well in 

5 advance of the actual operation of the group. 

The alternatives discussed above where groups are divided into various sub-groups, be 
they trees, hierarchical trees, clusters, etc allow for better scaling by simply requiring changes 
within the affected subgroup. It does become more complex when one of the local controllers for 
a group becomes untrusted, since replacement keys must be handled within a complex structure, 

1 0 and between different levels of influence. 

Various other mechanisms are defined in the literature to overcome these problems, 
including using sets and subsets of keys distributed amongst the group members, multiple keys 
distributed in such a fashion that each member cannot compute a new key value on its own, but 
rather requires active participation of the other members, etc. None of these mechanisms 

1 5 overcome the previously described problems which are inherent to such key distribution 
mechanisms. 
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The disclosures of all references mentioned above and throughout the present 
specification are hereby incorporated herein by reference. 

SUMMARY OF THE INVENTION 

1 0 None of the disclosed background art solutions provides a security system for the 

delivery of targeted digital media content through a packet-based network such as the Internet. 
Furthermore, none of the references teaches or discloses a mechanism for providing such a 
security system without requiring one-to-one key exchange, while still enabling selection of 
specific digital media content by particular end users. In addition, none of the references teaches 

1 5 or suggests a mechanism for broadcasting digital media content in a secure manner to a general 
group of end users, while still maintaining the desired degree of specificity in terms of those end 
users who actually use or access the digital media content. Also, none of the references teaches 
or suggests a mechanism for broadcasting and/or multicasting which is itself both efficient and 
secure, such that the security mechanisms do not detract from the performance of the actual 

20 delivery mechanism. 

Therefore, there is an unmet need for, and it would be highly useful to have, a system 
and a method for secure digital content delivery, which enables digital media content to be 
delivered through a packet-based network such as the Internet, without requiring any inherent 
security in the provisions of the network itself, and without requiring one-to-one key exchange. 

25 The present invention, in preferred embodiments thereof fulfills these needs by 

providing a system and a method for secure distribution of digital media content through a 
broadcast network, which may be a packet-based network such as the Internet and/or any type of 
IP network (even for those IP networks which are not packet-based networks). However, for the 
purposes of discussion only, the following description centers around packet-based networks, 

30 and more specifically IP networks which are packet-based networks, such as the Internet for 
example. In addition, the present invention is particularly concerned with broadcast and/or 
multicast transmissions through such networks. 

The security of the present invention does not require one-to-one key exchange, but 
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rather enables keys, and/or information required in order to build the key, to be broadcast 
through the network. The digital media content is then also preferably broadcast, but cannot be 
accessed without the proper key. However, preferably only authorized end-user devices are able 
to access the digital media content, by receiving and/or being able to access the proper key. 
5 Thus, the present invention is useful for other types of networks in which digital media content 
is more easily broadcast rather than unicast, in addition to packet-based networks. 

The present invention, in preferred embodiments thereof, supports the distribution of 
content to end user devices from one or more central distribution points, as in client-server 
models and variations thereof, and/or peer-to-peer distribution, for example between end user 
1 0 devices. In addition, the present invention, in preferred embodiments thereof; also supports 

distribution models within either of these mechanisms for unitary distribution, to a specified end 
user device, or broadcast/multicast distribution, to a plurality of end user devices. In any case, in 
order for the distributed content to be operative, for example to be "played back" or otherwise 
displayed, the recipient end user device is optionally and more preferably in communication 
1 5 with a broadcaster at least once before such a display is permitted. The broadcaster then enables 
the recipient end user device to play back or otherwise display the received content, for example 
by sending a code to the recipient end user device. Optionally, the broadcaster may require 
payment to be received before enabling the content for the recipient end user device. Thus, the 
present invention supports flexible distribution of content according to a number of different 
20 distribution models, while still preventing unauthorized play back or other display. 

According to preferred embodiments of the present invention, there is provided a 
combination of secure hardware and software to prevent and/or at least retard unauthorized 
access or "hacking". In order for access to the distributed content to be controlled, the content 
itself must be protected, for example by encryption or scrambling. Hereinafter, the term 
25 "scrambling" is considered to encompass both encryption, which involves the mathematically 
determined alteration of content or even only a part thereof to a form which cannot be read 
without the proper key, and a simpler form of scrambling, which involves the rearrangement of 
portions of the content, such that the content is only readable when properly rearranged. Indeed, 
even the simpler forms of scrambling can be effectively performed by altering, or otherwise 
30 rendering inaccessible, a small percentage of the overall content, after which the entire unit of 
content can no longer be displayed. By protecting the content itself, the present invention 
enables the content to be completely portable, and to be distributed freely, while still ensuring 
that control of access to the content is maintained by a central authority as required. 
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The preferred combination of hardware and software components enables the present 
invention to most effectively protect access to the content, while still enabling the user to easily 
and transparently play back, or otherwise display, the content. More preferably, the end user 
device which is used for the present invention includes a security module, for unscrambling the 
5 digitally scrambled content according to a received code. The security module optionally and 
more preferably features a renewable security submodule, such as a smart card with a smart card 
reader for example, although of course any suitable combination of software and/or hardware 
may optionally be used. The security module receives the necessary code from the broadcaster, 
and is then able to unscramble the received content for play back or other display. Most 
1 0 preferably, the operation of the security module is transparent or substantially transparent to the 
end user. 

According to the present invention, there is provided a method for creating a secure 
transmission mechanism for a plurality of end user devices in a packet-based network, 
comprising: providing a plurality of packets; securing the plurality of packets according to 
1 5 security information to form secured packets; transmitting the security information to more than 
one end user device simultaneously through the packet-based network; and multi-casting the 
secured packets to the plurality of end user devices. 

According to another embodiment of the present invention, there is provided a method 
for producing a conditional access (CA) system for use in a packet-switched environment 
20 (packet CA system) from a CA system for use in a broadcast environment (broadcast CA 
system), the method comprising: providing a broadcast CA system comprising at least one CA 
security characteristic; providing a packet-switched data transmission system including a 
security subsystem having a plurality of packet-switched security characteristics; and creating a 
mapping from the at least one CA security element to at least one of the plurality of 
25 packet-switched security elements, thereby producing a packet CA system. 

According to yet another embodiment of the present invention, there is provided a 
packet-switched conditional access (CA) system for use with an end-user playback device, the 
CA system comprising: a protected data receiver for receiving protected data protected with at 
least one key; an ECM packet receiver for receiving at least one ECM packet from a 
30 packet-switching network; and an ECM-based key generator for generating the at least one key 
from the at least one ECM packet. 

According to still another embodiment of the present invention, there is provided a 
method for providing an entitlement control message (ECM) based conditional access (CA) 
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system based on a packet-switching network comprising: receiving a plurality of ECMs via the 
packet-switching network; storing the plurality of received ECMs; and choosing, from among 
the plurality of stored ECMs, an ECM for providing access to CA-protected data. 

According to yet another embodiment of the present invention, there is provided a 
5 method for creating a secure transmission mechanism for a plurality of end user devices in a 
packet-based network, comprising: encrypting a plurality of packets with a key to form 
encrypted packets, the key having associated key information for determining the key; 
multi-casting the associated key information to the plurality of end user devices through the 
packet-based network, thereby obviating the need to send the associated key information to each 

1 0 end user device individually; and multi-casting the encrypted packets to the plurality of end user 
devices to form the secure transmission mechanism. 

According to still another embodiment of the present invention, there is provided a 
method for creating a secure transmission mechanism for a plurality of end user devices in a 
packet-based network, comprising: multi-casting a plurality of secured packets and security 

1 5 information to the plurality of end user devices, thereby obviating the need for a one-to-one 
transmission of the security information to each end user device individually and thereby 
forming the secure transmission mechanism. 

Hereinafter, the terms "file", "portion", "item" or "stream", with regard to digital content, 
are used interchangeably and refer to any unit of data for such digital content, whether as a 

20 functional unit such as a packet for example, or as a conceptual unit such as a television program 
for example. "Streamed" or "streaming" data may also be considered as being formed from any 
type of unit of data. 

Hereinafter, the term "display" refers to any type of playback or playing out of media 
content data for a user, or otherwise rendering such data sensible to one or more human senses, 
25 including, but not limited to, the audible production of audio data and the visible production of 
video data, and combinations thereof. 

Hereinafter, the term "network" refers to a connection between any two or more 
computational or other electronic devices which permits the transmission of data. 

Hereinafter, the term "computational device" includes any type of digital instrument 
30 which is capable of operating a software program. 

For the present invention, a software application could be written in substantially any 
suitable programming language, which could easily be selected by one of ordinary skill in the 
art. The programming language chosen should be compatible with the computational device 
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according to which the software application is executed. Examples of suitable programming 
languages include, but are not limited to, C, C++, Java and Assembly. 

In addition, the present invention could be implemented as software, firmware or 
hardware, or as a combination thereof. For any of these implementations, the functional steps 
5 performed by the method could be described as a plurality of instructions performed by a data 
processor. 

Hereinafter, "Applied Cryptography" by Bruce Schneier, John Wiley 2nd ed. 1996, is 
incorporated by reference as if fully set forth herein, for the teachings regarding cryptography 
and techniques for implementation thereof. 

10 

BRJEF DESCRIPTION OF THE DRAWINGS 

The invention is herein described, by way of example only, with reference to the 
accompanying drawings, wherein: 

FIG. 1 is a schematic block diagram of a background art system; 
1 5 FIG. 2 shows a flow diagram illustrating the production of the digitally scrambled digital 

content according to the background art; 

FIG. 3 is a schematic block diagram of a system according to the present invention for 
secure delivery of digital content through a packet-based network; 

FIG. 4 shows an exemplary format of an encrypted media content packet according to the 
20 present invention; 

FIG. 5 shows an exemplary format for ECM packets according to the present invention; 

FIG. 6 shows an exemplary EMM packet according to the present invention; 

FIG. 7 shows an exemplary but preferred implementation of the broadcaster headend of 
Figure 3 in greater detail according to the present invention; and 
25 FIG. 8 shows an exemplary but preferred implementation of the end-user client of Figure 

3 in greater detail according to the present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention features a system and a method for secure distribution of digital 
30 media content through a packet-based network such as the Internet, or another type of IP 

network, through multicasting and/or broadcasting of data. The security of the present invention 
does not require one-to-one key exchange, but rather enables keys, and/or information required 
in order to build the key, to be broadcast through the packet-based network. The digital media 
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content is then also preferably broadcast, but cannot be accessed without the proper key. 
However, preferably only authorized end-user devices are able to access the digital media 
content, by receiving and/or being able to access the proper key. Thus, the present invention is 
useful for other types of networks in which digital media content is more easily broadcast rather 
5 than unicast, in addition to packet-based networks and/or various types of DP networks. 

The present invention supports the distribution of content to end user devices from one or 
more central distribution points, as in client-server models and variations thereof and/or 
peer-to-peer distribution, for example between end user devices . In addition, the present 
invention also supports distribution models within either of these mechanisms for unitary 

10 distribution, to a specified end user device, or broadcast/multicast distribution, to a plurality of 
end user devices. However, for the purposes of the present invention, distribution by broadcast 
and/or multicast is considered to be particularly preferred. In any case, in order for the 
distributed content to be operative, for example to be "played back" or otherwise displayed, the 
recipient end user device must have been in communication with a broadcaster at least once 

1 5 before such a display is permitted. The broadcaster then enables the recipient end user device to 
play back or otherwise display the received content, for example by sending a code to the 
recipient end user device. Optionally, the broadcaster may require payment to be received 
before enabling the content for the recipient end user device. Thus, the present invention 
supports flexible distribution of content according to a number of different distribution models, 

20 while still preventing unauthorized play back or other display. 

According to a preferred embodiment of the present invention, the digital media content 
is securely transmitted through an IP network as the packet-based network (although non-packet 
based IP networks and/or non-IP but packet-based networks are also optionally implemented 
with the present invention). Optionally, the IP network is the Internet. However, transmission 

25 of such digital media content may be different than transmission of other types of data through a 
network such as the Internet. For example, a typical Internet-based content provider does not 
have a continuous or at least continuing relationship with the end user, but instead may only 
supply such content on a "one-off' or one-time basis. 

By contrast, a broadcaster of digital media content through an IP network may optionally 

30 wish to require a subscription or repeated payments for repeated accesses to the digital media 

content, although alternatively, the security information may optionally be "hard-wired" into the 
end user receiving device. Also, payment is more likely to be regular and repeated, rather than a 
single individual payment. Therefore, broadcasters of content through an IP network need be 
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able to handle many end users in a secure, scalable manner As previously described, one-to-one 
key exchanges are clearly not a reasonable, efficient, scalable mechanism for such security. 

The environment of BP networks such as the Internet is also based upon a particular group 
of standards, which define the protocols for communication through such a network, and which 

5 are different from the communication protocols and standards for transmission through a 

dedicated cable network, for example. These protocols must be used for communication through 
the network. Thus, the present invention is preferably constructed with agreed standards and 
protocols, of which an example is given below for an IP network, it being understood that the 
present invention is operative with substantially any type of packet-based network. 

1 0 Security for IP networks is currently based upon the IPSEC (Internet security framework) 

for creating the related set of standards, which are intended to provide a security protocol in the 
network layer as part of the network structure. The IPSEC standards assume but do not require 
that security is based upon key exchange protocols. These standards do not consider multicast 
scalability issues, particularly with regard to key exchange and management issues for large 

1 5 numbers of simultaneous users. However, the present invention is preferably compatible with 
the IPSEC standards, while differing in the actual application of the security protocol itself for 
example by associating the media content stream with the matching ECMs (entitlement control 
messages) according to the IPSEC announcement protocol. More preferably, at least certain 
IPSEC mechanisms are used for coordinating the delivery of security information such as ECMs 

20 to the end user devices, in order to ensure compatibility between the system of the present 
invention and other systems. 

According to preferred embodiments of the present invention, there is provided a 
combination of secure hardware and software to prevent and/or at least retard unauthorized 
access or "hacking". In order for access to the distributed content to be controlled, the content 

25 itself must be protected, for example by encryption or scrambling. Hereinafter, the term 

"scrambling" is considered to encompass both encryption, which involves the mathematically 
determined alteration of content or even only a part thereof to a form which cannot be read 
without the proper key, and a simpler form of scrambling, which involves the rearrangement of 
portions of the content, such that the content is only readable when properly rearranged. Indeed, 

30 even the simpler forms of scrambling can be effectively performed by altering, or otherwise 
rendering inaccessible, a small percentage of the overall content, after which the entire unit of 
content can no longer be displayed. By protecting the content itself, the present invention 
enables the content to be completely portable, and to be distributed freely, while still ensuring 
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that control of access to the content is maintained by a central authority. 

The preferred combination of hardware and software components enables the present 
invention to most effectively protect access to the content, while still enabling the user to easily 
and transparently play back, or otherwise display, the content. More preferably, the end user 
5 device which is used for the present invention includes a security module, for unscrambling the 
digitally scrambled content according to a received code. The security module optionally and 
more preferably features a renewable security submodule, such as a smart card and smart card 
reader for example, although any combination of hardware and/or software may optionally be 
used. The security module receives the necessary code from the broadcaster, and is then able 

1 0 to unscramble the received content for play back or other display. Most preferably, the 
operation of the security module is transparent or substantially transparent to the end user. 

The principles and operation of the present invention may be better understood with 
reference to the drawings and the accompanying description. 

Referring now to the drawings, Figure 3 is a schematic block diagram of an illustrative 

1 5 system according to the present invention for secure delivery of digital media content through a 
packet-based network as an exemplary but preferred implementation of the present invention, as 
previously described. 

As shown, a system 200 features an end user device 210 with an associated security 
module 220. Security module 220 optionally and preferably comprises a smart card, such that 

20 end user device 210 (or security module 220) would also feature a smart card reader, although of 
course other implementations are possible. For example, security module 220 could optionally 
be implemented as software alone, or as a combination of hardware and software. For the 
purposes of description below only and without any intention of being limiting in any way, 
security module 220 is assumed to include a smart card reader and smart card. 

25 End user device 210 also features a media player 230 for playing back or otherwise 

displaying at least one type of media content, such as audio content for example. End user 
device 210 operates an end-user client 240, which acts as the interface between end user device 
210 and a broadcaster headend 250. End user device 210 and broadcaster headend 250 
communicate through at least one channel 205. Two such channels 205 are shown, although 

30 optionally system 200 could feature more channels 205, or alternatively could feature only one 
channel 205. At least one channel 205 is preferably a network, which could be substantially any 
type of suitable network, including but not limited to, the Internet, a cable network or a satellite 
distribution mechanism. Optionally but more preferably, as described in greater detail below, 
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such a channel 205 is an IP network, such that communication between end user device 210 and 
broadcaster headend 250 is in the form of an IP session. However, the term "channel" itself may 
refer to any type of mechanism for data transmission, regardless of the type of data and/or the 
transmission medium. 

5 Broadcaster headend 250 in turn communicates with broadcaster 280 in order to provide 

at least the security information to end user device 210 through end-user client 240. 

More preferably, only security features are provided to end user device 210 through 
end-user client 240, and the actual content is transmitted separately. Optionally and more 
preferably, the actual media content is transmitted from a broadcaster content interface 290 to a 

1 0 client content interface 270, through a same or different channel 205 as the associated security 
information, such that the security information is not necessarily transmitted with the secured 
content. Client content interface 270 then passes the media content to media player 230, after 
such media content has been accessed with the necessary security information. Optionally and 
most preferably, each of client content interface 270 and broadcaster content interface 290 has 

1 5 access to a particular database for storing the security information, shown in Figure 3 as a client 
database 260 and a broadcaster database 295 respectively. Each of client database 260 and 
broadcaster database 295 is preferably secured with some type of security mechanism. 

The security features for the content are preferably provided by encrypting the content, 
such that access to the media content is only possible for authorized users, although optionally 

20 contact with broadcaster 280 and/or broadcaster headend 250 is not required. However, rather 
than using one-to-one key exchange, which would be very inefficient as it would require specific 
transmission of the key to each end user device 210, preferably access information is broadcast 
or multicast to a plurality of end user devices 210. This information could be sent in the form of 
a particular message through channel 205, in which case the information would be a permission 

25 message. The presence or absence of information which is locally accessible by each end user 
device 210 then determines whether the broadcast or multicast access information is actually 
usable by a particular end user device 210, more preferably in order to create a key which is then 
used to access the media content by security module 220. Optionally, if a plurality of different 
broadcasters 280 are present, separate storage space for credit information and/or other broadcast 

30 information is preferably provided on said security module 220 for each broadcaster 280. 

According to a particularly preferred embodiment of the present invention, the access 
information is preferably distributed through an ECM (control message), which more preferably 
enables end user device 210 to create the correct key and as such may be considered to be an 
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example of a permission message. For example, the ECM could comprise a seed which is input 
into a function performed by security module 220, the result of which is the key required to 
access the media content, by decrypting the media content or otherwise rendering the media 
content into a displayable format. 
5 Optionally, the ECM is broadcast to all end user devices 210, but the particular end user 

device 210 is more preferably only able to generate the key if this end user device 210 also 
receives an EMM, or entitlement message, from broadcaster headend 250. The EMM is 
optionally and more preferably used for periodic renewal of security module 220, such that 
without periodic receipt of such an EMM, security module 220 eventually is no longer able to 

1 0 access the media content, since security module 220 is no longer able to use the ECM 

information to generate the key for decrypting or otherwise accessing the media content. More 
preferably, each EMM contains one or more content service identifiers, which may be an 
alphanumeric string for example. Although the term "service identifier" is used herein, it should 
be noted that in face such identifiers may optionally refer to any type of authorization, and not 

1 5 only authorizations for services. At least one such identifier is also present in the ECM, such that 
security module 220 is more preferably only able to access those ECMs for which a matching 
service identifier has been delivered in a EMM. It should be noted that there is not necessarily a 
one-to-one relationship between each EMM and/or each service identifier and each ECM, since 
service identifiers may optionally be used for granting permission to access more than one ECM, 

20 and since each ECM may optionally contain more than one such service identifier. Most 

preferably, each service identifier expires after the multi-cast session has finished, in order to 
prevent security module 220 from being able to grant access to "old" previously transmitted 
data, although optionally the service identifier could then be renewed and used again for a 
different such session. 

25 According to an optional but preferred embodiment of the present invention, for "pay per 

view", an EMM is not necessarily required, although it may optionally be required in order to set 
those conditions under which the purchase may be made, such as possession of a particular 
number of credits by security module 220 for example. Instead, security module 220 would 
preferably receive a ECM which allows a "free preview", and/or which contains the necessary 

30 information for purchasing the content. Such an ECM could optionally and more preferably be 
labeled with a "general" or generic service identifier, such that the ECM would be accepted by 
any security module 220 and/or by security modules 220 of a particular type of end user device 
210. The user could then more preferably instruct end user device 210 to purchase the content, 
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for example through security module 220. Optionally and most preferably, credits or other units 
of exchange for content are kept on security module 220, particularly if security module 220 is 
implemented with a smart card, in order for the account of the end user to be immediately or 
later debited for the purchased content. Also optionally, an EMM could be used to deliver 
5 credits, tokens or the like, to enable end user device 210 to be used to purchase the "pay per 
view" content. 

According to the optional but preferred embodiment of the present invention, the content 
of the EMM is stored securely in the smart card or other secure portion of security module 220. 
Thus, the key, or information required to generate the key, may optionally be broadcast, while 

1 0 the ability to use such a key is preferably still controlled by broadcaster 280, through the 
distribution of some type of permission message for example. 

The EMM itself could also optionally be sent to a plurality of different end user devices 
210 at one time, as a broadcast or multicast, such that a group of end user devices 210 would 
receive the information at once. For example, a particular EMM could be designated for one 

1 5 group of end user devices 210, according to a particular subscription plan or other type of 

payment structure, and/or according to the network address of the members of the group of end 
user devices 210. Alternatively or additionally, a particular ECM may preferably be blocked for 
a particular group of end user devices 210 for a "blackout". Such a blackout may optionally be 
implemented for such a group according to geographical location, for example in order to obey 

20 laws in a particular country, and/or according to characteristics of individual end users within the 
group, for example according to subscription and/or parental rating informatiorL Preferably, the 
blackout is determined through a blackout identifier which is contained in the ECM, for 
identifying an end user device blocked from accessing the content of a particular ECM, such that 
access may also include the ability to use a control word and/or information for generating such 

25 a control word which is provided through the ECM. 

Other types of differential access may also optionally be implemented within the present 
invention such that differential access is preferably defined for different levels of users. For 
example, such differential access can optionally be determined within the ECM based on service 
identifiers, where multiple service identifiers apply to one transmission and are contained in a 

30 single ECM, such that a blackout would preferably be applied to the services which are not 
allowed. 

For a packet-based network, and particularly for an IP network such as the Internet, the 
EMM and ECM information is preferably sent through channel 205 according to a particular 
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packet format. End-user client 240 would receive a packet for ECM information which would 
optionally and preferably contain a header for specifying those service identifiers to which the 
packet information would apply, thereby also specifying which security modules 220 are able to 
access the ECM information, since preferably only those security modules 220 with the 
5 corresponding service identifier would be permitted to access the ECM information. Security 
module 220 would then compare the specified service identifiers) to the service identifier 
information stored by security module 220, and/or within an associated component, such as a 
smart card for example. If the packet is relevant to such a stored service identifier, then security 
module 220 would read the ECM information contained within the packet, in order to be able to 

1 0 access particular media content. Such a mechanism would enable ECM information to be 

generally transmitted to a plurality of end user devices 210, but only to be used by those end user 
devices 210 for which it is relevant. 

More preferably, broadcaster 280 controls the connection between each ECM and the 
media content to which the ECM provides access. If the use of EMM information/ service 

1 5 identifiers is implemented as preferred, broadcaster 280 also preferably controls the connection 
between each service identifier and the ECM information to which the service identifier grants 
access. Such control enables broadcaster 280 to determine which end user device 210 receives 
access to which media content, for example according to payment by the end user, subscription 
basis and/or other factors, without requiring broadcaster 280 to specifically transmit a key to 

20 each end user device 210 on a one-to-one basis. Furthermore, since most preferably both ECM 
information and service identifiers are renewed periodically, and indeed most preferably must be 
renewed periodically, the ability to broadcast or multicast ECM information and/or service 
identifiers to end user devices 210 is even more important, since otherwise significant amount of 
bandwidth for channel 205 and computational resources would need to be devoted simply to 

25 renewing the access information. 

Optionally, broadcaster headend 250 repeatedly transmits the ECM while the media 
content is being received and displayed by end user device 210, in order to require security 
module 220 to repeatedly derive the key for decrypting or otherwise accessing the media 
content. This requirement provides additional security, such that if the key or other security 

30 information is somehow obtained by an unauthorized user, changing the security information 
would prevent the unauthorized user from accessing all of the media content. Additionally or 
alternatively, repeatedly transmitting the ECM has the advantage of enabling an authorized 
security module 220 to rapidly access the multi-cast content, even if access is initiated in the 
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middle of a multi-cast session. Each period for which the security information is transmitted 
and/or valid may be termed a "key period", optionally for validating the ECM. The length of the 
key period may optionally be determined according to a length of time, for example, and/or 
could be determined by the duration of a particular multi-cast session. Other optional but 
5 preferred features of the key period include, but are not limited to, transmitting the security 

information, such as the ECM, in advance of the media content; short duration for the key period 
itself and/or rapid key change (on the order of seconds between changes); and buffering 
previously received ECM information and/or previously derived keys, if such information is not 
changed but only renewed. Both optional features prevent access to the media content from 

1 0 being disrupted because the transmission of the ECM is delayed, which is particularly important 
for IP networks and other types of networks for which transmission of the packet is not 
guaranteed. A corresponding preferred feature of EMMs is an authorization period, such that 
EMMs are preferably only valid for the authorization period, after which a new EMM must be 
received. Thus, the security information is still renewed, while also supporting access of 

1 5 authorized end users to the media content, even in a non-reliable network environment such as 
the Internet. 

According to a preferred embodiment of the present invention, end user device 210 
operates a verification module 300 for verifying both the received security information from 
broadcaster headend 250 and the authenticity of the information contained within security 
20 module 220. 

Verification module 300 preferably filters all communication external to end user device 
210, whether from broadcaster headend 250 or from another communication source, in order to 
determine whether such communication should be passed to security module 220. For example, 
verification module 300 could optionally have access to identifiers for identifying particular 
25 information which is contained in EMMs, in order to determine whether security module 220 
has access to such EMMs. Such identifiers may optionally include, but are not limited to, 
identifiers for determining access according to at least one characteristic selected from the group 
consisting of a characteristic of end user device 210 and a characteristic of information stored on 
end user device 210. 

30 Verification module 300 would then optionally be able to determine whether a received 

packet is relevant to that security module 220, according to the EMM information as previously 
described. Furthermore, verification module 300 could also optionally and preferably have 
access to the service identifiers which are stored in security module 220, in order to determine 
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whether a particular ECM should be passed to security module 220 for further processing. In 
addition, more preferably verification module 300 also determines the authenticity of EMMs 
and/or ECMs, for example by determining whether such messages are digitally signed for 

verification. 

5 According to other optional but preferred embodiments of the present invention, 

particularly in implementations containing a plurality of broadcaster headends 250, broadcaster 
headends 250 are distinguished with different levels of authorization and/or abilities. For 
example, some broadcaster headends 250 may only be allowed to transmit content based upon 
the type of service identifier. 

10 In order to ensure compatibility between system 200 and other mechanisms for IP 

network security, preferably system 200 is in compliance with the IPSEC (Internet security 
framework) framework for determining standards, even if the features provided in these 
standards are not always completely used. As previously described, security for IP networks is 
currently based upon the IPSEC set of standards, which are intended to provide a security 

1 5 protocol in the network layer as part of the network structure. Optionally and more preferably, 
one of the announcement protocols of the IPSEC standards is used in order to associate 
encrypted or otherwise protected media content with the security information which is required 
for access, such as the particular ECM or ECMs for example. For any type of announcement 
protocol which is used, optionally and more preferably, the packets associated with such a 

20 protocol are encrypted, most preferably with a key which is not session-based but which is 
available and accessible over a longer duration (for example, during a particular subscription 
period). One non-limiting example of a standard for providing such encryption is the SAP 
(session announcement protocol) protocol of IETF. Alternatively, the announcements may also 
be delivered as plaintext, without encryption. However, for certain types of announcements, 

25 access to the information would preferably and preferably be restricted, for example only to 

those end user devices and/or security modules associated with a subscription Alternatively or 
additionally, certain announcements could optionally and preferably be more freely available, 
for example in order to deliver general information such as a "free preview mode" for 
previewing content which could then optionally be purchased, which would optionally and more 

30 preferably be available to any end user device having an associated smart card (or other general 
characteristic). 

One non-limiting example of a suitable IPSEC announcement protocol is the SDP 
(session description protocol), as described in RFC 2327, which is hereby incorporated by 
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reference as if fully set forth herein. Of course, other types of announcement protocols could 
also optionally be used, such as CDF (Channel Definition Format) and new XML-based 
proposals for example. The protocol is intended to be able to describe multimedia sessions, in 
which a "session" is a set of multimedia sending and receiving devices, and the streams of 
5 multimedia data which flow from sending devices to receiving devices. The description of such 
sessions is intended to permit those participants in the session to receive information about 
initiating participation, and also about the session itself. With regard to the present invention, 
SDP is optionally and preferably used for conveying information about the protected media 
content which is transmitted from broadcaster headend 250 to end user device 210, and to 

1 0 coordinate between each ECM and the associated protected media content. 

SDP is a text-based protocol, formatted by lines, in which each line has the format 
type - = < value > . This information would be contained within a packet as the payload for that 
packet. The information contained in the <type> field is exactly one character and is 
case-significant. The information contained in <value> is a structured text string. The protocol 

1 5 permits proprietary extensions to the list of various types which are permitted, by using the type 
a for attribute. Values of type a can optionally be used for the entire session, but alternatively 
may only be used for particular components within the session. 

SDP is stated to be usable for transmitting encryption keys for one-to-one key exchange 
mechanisms. However, the background art does not teach or suggest the use of SDP for 

20 transmitting security information through the use of the a or attribute parameter. The present 
invention uses the attribute parameter for associating an ECM with the relevant session and/or a 
portion of the session, by transmitting the ECM as the value for the attribute. In addition, the 
attribute parameter could also optionally be used in order to limit access to different portions of 
any given service, for example based upon payment schemes or authority levels. For example, 

25 the line containing the ECM information could optionally have the format a=ecm:<CASID><IP 
address> < UDP port#>, in which "CASID" is an optional parameter for identifying the vendor 
of the particular system. 

Another BPSEC standard which is optionally and preferably used for the present 
invention is the ESP (IP encapsulating security payload) protocol, as described in RFC 2406, 

30 which is hereby incorporated by reference as if fully set forth herein The ESP format is 

optionally and preferably used in order to encapsulate encrypted content and to synchronize 
content packets with ECM information. ESP provides a header, containing information about 
security services, which is intended to be inserted after the IP header and before the upper layer 
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protocol header for IP packets being transmitted in the transport mode. According to the 
standard, ESP is used to provide confidentiality, data origin authentication, connectionless 
integrity and limited traffic flow confidentiality. 

The first value in the ESP header is the 32-bit security parameters index (SPI), which is 

5 stated in the standard to be used for uniquely identifying the Security Association for the packet, 
in combination with the destination IP address and the security protocol. The present invention 
uses the SPI value in order to associate a packet containing encrypted media content with the 
ECM that is required to generate the key which encrypted that media content. More preferably, 
client database 260 contains a table for determining this association, such that the SPI is at least 

10 part of a set of information for identifying the correct ECM for the media content, and hence the 
correct key which is to be used for decrypting the encrypted media content. Optionally, this set 
of information also includes the destination IP address, the protocol being used (such as ESP for 
example) and the port to which the media content is sent. The port information is preferred when 
the security information, such as the ECM, is sent to a particular port of end user device 210, for 

1 5 example when multiple vendors may supply end user device 210. However, only the SPI is 
preferably used in order to be able to announce to security module 220 that the ECM or other 
security information has been changed when the key period changes. Therefore, a range of SPI 
values is preferably provided, such that each of change of SPI value indicates a change to the 
required ECM, and hence to the key which must be generated in order to be able to decrypt the 

20 media content. 

The background art does not teach or suggest the use of SPI values for indicating the 
initiation of a new key period, and hence the change of ECM information which is required. 
However, this implementation is particularly useful since it enables security module 220 to 
receive a plurality of different ECMs in advance of their actual use, without compromising the 

25 ability of broadcaster headend 250 to still control access by end user device 210. Without the 

SPI value itself, more preferably end user device 210 is not able to determine the correct ECM to 
be used to generate the key, since as previously described, the SPI is at least a part of the set of 
information which is required for determining the correct ECM to be used for decrypting or 
otherwise accessing the media content. Furthermore, the advantage of the SPI over background 

30 art methods for synchronization, such as using a binary (odd/even) value for synchronizing 
between the ECM and the media content, is that the SPI can optionally have a large range of 
values. In a non-reliable/potentially latent environment such as the Internet, which does not 
guarantee delivery of packets and which may as a result have a large latency period for such 
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delivery, the large range of values effectively removes the dependence of each packet from the 
previous packet, so that receiving packets out of transmission order and/or even failing to 
receive a packet would not disrupt the security scheme. 

According to an exemplary but preferred implementation of the present invention, the 
5 format of each encrypted media content packet is preferably as shown in Figure 4. As shown, an 
IP header 400 for the packet is followed by the SPI value 410, as determined by the ESP 
standard as previously described. Next, a 32-bit sequence number 420 is included, also as 
determined by the ESP standard. Sequence number 420 starts at the value "1" and is 
monotonically increased for each packet until the maximum value (2 32 -l) is reached, at which 

1 0 point the associated SPI value 410 is no longer valid and the next SPI vahie from the range of 
permitted values must be used. In fact, the maximum value may not be reached, since sequence 
number 420 is preferably reset for each key period when both the security information for the 
key and SPI 410 change. 

The next value in the encrypted packet is optionally and more preferably an initialization 

1 5 vector (IV) 430, which may be required for operating certain types of encryption methods such 
as RC4, for example in order to improve the strength of the encryption by increasing the 
randomness thereof, as is known in the art. The format and length of IV 430 depend upon the 
particular encryption method. 

The packet next features the encrypted media content itself^ which is shown as a payload 

20 440 for the packet. Payload 440 may also optionally include such information as the transport 
layer (UDP or TCP) header. After payload 440, the packet preferably features a PAD length 450 
of one byte, which is always equal to zero. The packet then optionally and preferably features a 
next header 460, the value of which preferably depends upon the type of data which is included 
after the ESP header, in order to indicate whether the packet is being transmitted in transport 

25 mode or tunnel mode. 

Figure 5 shows an exemplary format for ECM packets, which are preferably 
encapsulated as regular clear UDP packets. As shown, the ECM packet features an IP header 
500, followed by a UDP header 510. After UDP header 510, a UDP payload 520 more 
preferably has two components: an SPI 530 for indicating the correct associated SPI value for 

30 the ECM information, and an ECM information payload 540, which contains the actual ECM 
information. However, substantially any other suitable format of packet could be used for 
transmitting the ECM information, as long as the ECM information is somehow associated with 
the correct SPI, so that end user device 210 is able to determine which ECM should be used with 
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received encrypted media content. 

Preferably, verification module 300 is able to filter ECM packets in order to determine 
which such packets are relevant to security module 220 (both not shown; see Figure 3). Such 
filtration is optionally and more preferably performed by comparing previously distributed 
5 information from the announcement message about the association between the content and the 
combination of the IP multicast, UDP port and SPI values from the ECM packet, which are 
most preferably provided in the header. Most preferably, the IP address of the ECM packet is 
announced with the announcement message, as previously described, such that security module 
220 may effectively "filter" the ECM packets by only listening to those IP address(es) for ECM 

1 0 packets for which security module 220 has an authorization, for example from the relevant 
EMM. Thus, only relevant ECM packets are preferably passed to security module 220. 

According to other preferred embodiments of the present invention, and as specifically 
described with regard to Figure 6, the EMM information, such as the service identifiers), is 
transmitted in a packet having a particular structure. This packet is then more preferably filtered 

1 5 by end-user client 240 and/or verification module 300 (see Figure 3) in order to determine if the 
EMM information is relevant to the particular end user device 210 before the EMM packet is 
delivered to security module 220 of that end user device 210. Such filtration is preferred in 
order to avoid overwhelming security module 220 with a huge amount of non-relevant EMM 
information. 

20 In order to assist end-user client 240 to rapidly filter EMM packets, optionally and more 

preferably such packets have the structure shown in Figure 6. As shown, an exemplary EMM 
packet format is described with regard to implementation as an IP/UDP packet. The packet 
features an IP header 600 and a UDP header 610. Next, at least one, and preferably a plurality 
of, EMM 620 are included. Each EMM 620 optionally and more preferably features a filter type 

25 630, which may be unique, group or general. Filter type 630 determines whether each EMM is 
allocated to a single IP address for a particular end user/subscriber (unique), all IP addresses 
(general) or a group of DP addresses (group). For both group and general addresses, the EMM 
may optionally be sent on a fixed multicast BP address, which could then be distributed based on 
regions in order to optimize EMM delivery performance and client performance. Such a 

30 multicast DP address may optionally be configured according to MADCAP (Multicast Address 
Dynamic Client Allocation Protocol) for example. Filter type 630 may also optionally and more 
preferably contain information related to a particular characteristic or characteristics which are 
stored on security module 220, such as a smart card for example, and/or are otherwise stored on, 
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or accessible to, end-user client 240 (both not shown; see Figure 3). One non-limiting example 
of such a characteristic would be an identifier for security module 220 itself; such as a smart 
card identifier for example. 

Similarly, after each filter type 630, an address 640 contains information as to whether 
5 the EMM is unique, group or general in type. A length field 650 is then used, after which an 
EMM payload 660 contains the actual EMM information. This packet structure is one example 
of a format which may be optionally implemented for greater ease of filtering by end-user client 
240. 

EMMs may also optionally and alternatively or additionally be sent by e-mail as e-mail 

1 0 messages over the SNMP (simple network message protocol) protocol, such that end-user client 
240 and/or end user device 210 could then optionally retrieve the EMMs as e-mail messages, for 
example at the initialization of operation of end user device 210 for each session. 

Figure 7 shows a schematic block diagram of a preferred embodiment of broadcaster 
headend 250. As shown, broadcaster headend 250 optionally and preferably features a plurality 

1 5 of components for performing encryption of the media content, and for synchronizing 

transmission of encrypted or otherwise protected media content and the corresponding security 
information and/or access schemes for determining access to the protected media content. A 
traffic system 700 receives information about the media content, metadata and schedules of new 
IP sessions. Traffic system 700 also preferably ensures that sufficient bandwidth is available on 

20 channel 205 (not shown) and/or within broadcaster headend 250 before scheduling IP sessions. 
In addition, traffic system 700 optionally and more preferably determines if the media content is 
within an authorized size range. If sufficient bandwidth is available and/or if other criteria are 
met, then traffic system 700 preferably generates the appropriate access criteria for being 
included in the ECM, and configures the system-wide security association parameters, which are 

25 required for enabling end user device 210 to eventually obtain access to the protected media 
content. Examples of access criteria include but are not limited to, price (particularly for the 
previously described pay-per-view system), parental rating and "blackout" criteria, which are 
criteria for determining whether a particular end user device 210 may not be granted access to 
the associated content. Traffic system 700 may optionally be implemented as a traditional 

30 television traffic system or data content provider system. In the latter type of system, the content 
provider has remote access to the system in order to define and schedule multicast sessions 
asynchronously as desired. 

Once traffic system 700 has scheduled the new IP session, with the appropriate security 



WO 01/91465 



PCT/IL01/00469 



29 

parameters, information about the IP session is preferably passed to a transmission server 710. 
Transmission server 710 preferably announces each IP session and transmits the content to the 
appropriate IP address and UDP port of end user device 210 according to the schedule which is 
determined by traffic system 700. The media content and associate security information is then 
5 preferably passed to an DPSEC encryption system 720 for encryption and packaging into packets 
("packetization") as described in greater detail below. 

Transmission server 710 itself optionally and more preferably also features a separate 
announcement server 725 for creating and transmitting announcement messages, for example 
according to the SDP standard as previously described. Announcement server 725 preferably 

1 0 receives information from traffic system 700 concerning the schedule for the IP session, 

addresses of content and an ECM address pair (IP address and client port address), as well as the 
identifier for the ECM itself The announcement message preferably includes all of these 
different types of information, and is preferably transmitted on a well known port address, 
although the session itself may optionally be conducted on different client ports. The address for 

1 5 the announcement may itself optionally be transmitted to each end user device 210 (not shown) 
automatically through standard digital video broadcast (DVB) streams such as the program 
specific information (PSI) and/or programming mapping table (PMT) streams, or the service 
information (SI) or service definition table (SDT) streams. 

Turning back to traffic system 700, the information concerning the media content to be 

20 transmitted, the identity of the recipient end user devices 210, optionally subscriber information 
and other types of information are preferably sent from an external management server 730, 
which manages and configures separate network entities. Examples of such entities include, but 
are not limited to, subscribers, addresses, access criteria and bandwidth. External management 
server 730 also passes the necessary information to, and manages the activities o£ a content 

25 encryption server 740, which may optionally operate according to any standard encryption 
method, including but not limited to, AES (advanced encryption standard), and DES. 

Content encryption server 740 is also optionally and preferably in communication with a 
synchronization system 750. Synchronization system 750 preferably synchronizes the 
transmission of announcement messages, media content and ECMs, after receiving information 

30 about the IP sessions from traffic system 700. The transmission of EMMs is not necessarily 
synchronized with the transmission of these other messages, as long as the service identifiers) 
are transmitted in a timely manner before the ECM is to be received and/or used. Furthermore, 
an EMM is not necessarily transmitted at all, such as for the optional "pay per view" 
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mechanism, which as previously described does not require EMMs for operatioa 
Synchronization system 750 also more preferably assigns all system addresses, including IP and 
port addresses. 

Once the session has been scheduled, the security information has been selected 
5 (including at least one ECM for encrypting the media content), and the content has been 
synchronized with the security information, content encryption server 740 then encrypts the 
actual media content itself More preferably, the media content is encrypted with the key which 
would be generated from the ECM, as received by the end user device (not shown; see Figure 3). 
Optionally and most preferably, content encryption server 740 contains an ECM generator 745 

1 0 for generating the security information. ECM generator 745 generates a control word for 
actually encrypting the media content. 

The same control word must then be generated again at the end user device (not shown) 
in order for the media content to be accessed and displayed. The ECM itself must also be 
generated from at least the control word, and more preferably also from access criteria, 

1 5 concerning those end user devices (not shown) which are allowed to have access to the media 
content. However, the present invention is not limited to this type of mechanism, but may also 
include implementations in which ECM generator 745 does not generate the control word, which 
is instead generated separately by a separate control word generating module (not shown). For 
the latter type of implementation, preferably ECM generator 745 generates the ECM from a 

20 combination of the control word and access information. 

Next, ECM generator 745 preferably schedules transmission of the corresponding ECM 
and transmits the ECM when ready. Also, ECM generator 745 optionally and preferably inserts 
the SPI within the packet containing the ECM information, as previously described. If the SPI is 
used, then ECM generator 745 also optionally and preferably increments the SPI counter at each 

25 key period change, also as previously described. 

A corresponding service identifier is preferably determined (as one type of access 
criteria) for association with an ECM, in order to be able to inform the end user devices as to 
whether they are authorized to use the ECM. The EMM information (service identifier) is 
preferably placed in a EMM by a separate EMM generator 755. The EMM information is 

30 optionally sent on a fixed multicast IP address and port to the end user devices. 

The encrypted content is then passed to an IPSEC management system 760, which 
manages the process of forming packets and including the IPSEC encryption information at 
IPSEC encryption system 720. IPSEC management system 760 more preferably manages the 
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security policy database and the security association database based upon input received from 
synchronization system 750 and content encryption server 740. IPSEC management system 760 
optionally and preferably stores information in the security association database concerning the 
type of encapsulation protocol for creating the packets, such as ESP for example as previously 
5 described; the type of encryption method which is used for encrypting the actual media content, 
such as RC4, DES or 3DES, for example; the type of DP mode for transmitting the packet, such 
as transport mode for example; and information about the initialization vector (TV) if in fact one 
such vector exists. 

IPSEC management system 760 also preferably merges the control word, security 

1 0 association parameters and SPI information with BP multiplexing information. 

IPSEC encryption system 720 preferably performs two functions: encryption according 
to the IPSEC standards, and packet formation. The packets are formed by receiving the 
incoming encrypted content and associated information, according to the DPSEC standards as 
previously described. More preferably, the packets are formed by adding the ESP header with 

1 5 the appropriate SPI to the encrypted content, after which the packets are transmitted. Optionally 
and more preferably, packets containing security information such as ECMs and EMMs, and 
also announcement messages, are forwarded for distribution through the IP network without 
being transformed into packets by IPSEC encryption system 720. IPSEC encryption system 720 
then performs encryption of the packet contents as required. 

20 According to optional but preferred embodiments of the present invention, the previously 

described management and encryption system may be optionally implemented with Simulcrypt 
protocols. These protocols enable an IPSEC-enabled encryptor, such as IPSEC encryption 
system 720 for example, to encrypt the IP content (streams or files) once based on a unique key 
(or control word) generated by a local key generator. This key may then optionally be sent over 

25 standard Simulcrypt protocols to multiple separate ECM generators of separate CA (content 

access) systems to enable secure ECM delivery across these different content access systems. In 
other words, with one encrypted content stream and/or file and one key or control word, multiple 
ECMs may be possible. 

Figure 8 shows an exemplary but preferred implementation of end-user client 240 in 

30 greater detail. As shown, end-user client 240 preferably features an IPSEC decryption system 

800 for receiving all packet data, which is preferably IP data, and also for decrypting such data if 
necessary. IPSEC decryption system 800 is preferably able to retrieve the necessary SPI and 
other security related information, in order to decrypt the packet data. 
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The decrypted data is then passed to an application 810 which has requested this data. 
Each application 810 preferably acts as a trigger for receiving more data, by opening a socket 
and receiving content from DPSEC decryption system 800. 

EPSEC decryption system 800 also preferably communicates with an IPSEC management 
5 system 820 for implementing the security policy database and security association database, for 
storing the necessary security information. Such information is optionally stored in client 
database 260 (not shown; see Figure 3). IPSEC management system 820 preferably manages 
EMM information and other security information as well, including, but not limited to, source IP 
and source port addresses; destination IP and port addresses; SPI, control word and IP 
1 0 multiplexing information. EP multiplexing information may include such information as the type 
of encryption algorithm, initialization vector, transport or tunnel mode, and so forth. All of these 
components are preferably in communication with security module 220 and/or verification 
module 300 (not shown; see Figure 3). Optionally, IPSEC management system 820 also 
manages the functions of security module 220 as well. 

15 

One optional embodiment for the present invention involves membership revocation for 
an end user device which has left a group, involving revocation of authorization for service 
identifiers and/or limiting the key period for the service identifiers. The remaining group 
members then require reauthorization, although with short key periods, such reauthorization 

20 would be frequently performed without a special procedure. It is even possible to make a 
reauthorization necessary within a multi-cast session. The local security module could 
optionally prevent access to the service identifiers and/or other authorization information. As an 
example, a system of rules for this usage of service identifiers is optionally and preferably 
determined at the broadcaster headend, and then transmitted to the smartcard (security module). 

25 Revocation is optionally performed by sending information with an EMM, although 

alternatively or additionally, revocation is preferably performed with an ECM. For example, 
revocation is optionally performed by sending an EMM hidden within an ECM, thereby causing 
the smart card or other local security module to obtain or lose authorization, according to the 
desired outcome. 

30 The method of the present invention also avoids another major loophole and problem for 

multicast security, with regard to key sharing conspiracies. In the standard model in the 
background art, the keys can be shared quite easily, since they tend to last a long time. In the 
present invention, the keys (control words) are preferably changed very often according to a 
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relatively short key period, so sharing is more difficult, certainly for streaming data. This 
solution also prevents the reuse of old keys and/or old content, since any current key is then 
preferably unable to decrypt previous or future transmissions of content. Standard models for 
multicast in the background art do not deal with this problem efficiently. 

5 

The previous discussion has clearly demonstrated the utility of the present invention in a 
broadcaster-controlled network environment, in which one broadcaster transmits data to a 
plurality of end user devices simultaneously through a network, particularly a packet-based 
network in a non-reliable environment or at least an environment in which reliability is not 

1 0 guaranteed, such as the Internet or other IP network. Other security mechanisms have been 
developed for such network environments, but they have not been shown to be useful for 
broadcast data, as they are concerned with security for a session between two parties. 

As an example, the SSL (secure sockets layer) protocol may be considered. SSL is 
clearly only useful for secure, reliable communication between two hosts through a network, 

15 unlike the present invention, such that SSL is not only not intended for multicasting, but in feet 
is not usable for multicasting. SSL also relies upon a trusted certificate authority; once both 
parties have received such certificates, they mutually trust each other completely. By contrast, 
the present invention requires continuous or at least repeated authentication of the end user 
device, thereby preventing an unauthorized user from gaining initial access and then continuing 

20 to receive services from the broadcaster. Also, SSL only supports the TCP/IP connection 

protocol, but does not operate over the UDP connectionless protocol, while the method of the 
present invention works with both the connection and connectionless protocols. Thus, SSL is 
not scalable to a large number of end user devices, while the present invention is scalable to such 
a large number of end user devices. 

25 According to another preferred embodiment of the present invention, there is provided a 

mechanism for transferring content through a "peer-to-peer" system. The term "peer-to-peer" 
refers to the transfer of data, such as the content and/or associated security information, between 
end user devices. This preferred embodiment may be used to reduce the load on the central 
server or other central authorization entity. 

30 There are various scenarios that are possible in order to manage peer-to-peer sessions. 

The simplest model preferably features a security server at each peer end user device. The 
security server could optionally be implemented with any platform which is capable of secure 
storage and secret cryptographic calculations, whether in protected hardware or software. One 
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non-limiting example of such a platform is a smart card with a smart card reader. Each such 
security server would be capable of all the procedures previously described as occurring in the 
host, at the broadcaster/broadcaster headend in Figure 3, for example. Each host can optionally 
and preferably generate its own list of service identifiers and Control Words or another type of 
5 key to be used to authorize any other peer end user device (or set of hosts), and to encrypt 
communications. 

Authorizations are more preferably performed with locally generated EMMs signed by 
the local security server, while data is more preferably encrypted by the local security server. 
SDP announcements would be generated locally and digitally signed to authenticate the session 

1 0 call. One potential drawback of this mechanism is the significant potential for collisions for all 
elements, particularly with regard to service identifiers. Therefore, as a preferred feature, for all 
sessions with a membership group of peer devices, each local host would optionally and 
preferably coordinate through a central host, a Group Controller. This coordination could 
optionally occur in advance of a specific session; for example, each new local host which 

1 5 becomes a member is then assigned a range of service identifiers, for example. Alternatively, 
this coordination could optionally be performed through the packet-based network in "real 
time", such that before or at the start of each session, the local host would request an identifier 
from the Group Controller (GC). This GC is preferably not a classic Group Controller as defined 
in the discussions above, but would have a very limited function of coordination, with minimal 

20 overhead. 

Once recourse is made to Group Controller involvement in peer to peer interactions, a 
model may optionally and more preferably be implemented in which the Group Controller plays 
an even more significant role in the peer to peer session. In addition to the coordination and 
assignment of service identifiers, the Group Controller may also optionally schedule all 
25 synchronization requirements for the system including announcements and access criteria 

generation. Optionally and most preferably, the GC generates the ECMs to be transmitted, while 
locally generating the CW (control word; used for local creation of the control word as 
previously described). 

For local hosts that are very limited in terms of computational power and/or bandwidth, 
30 the model is optionally altered to enable all elements to be generated and/or coordinated by the 
GC, including data encryption and CW generation, apart from the setup parameters, which are 
defined by the local hosts. 

An intermediate version of the above model preferably features a general broadcaster 
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headend (as for Figure 3, for example) to register a session and to generate a steady flow of CW 
to encrypt and decrypt peer to peer sessions. Such a model may be preferably implemented if the 
local headend is not considered secure enough to have a CW generator on-site, particularly in 
cases where the CW generator is implemented in software. For this model, each EMM carrying 
5 service identifiers is supplied by the central, general headend upon registration, but alternatively 
may be generated by each peer for another peer. 

Any suitable combination of the above features is considered to be within the scope of 
the present invention, and may optionally be implemented as practicable depending upon the 
needs of the specific session, and the capabilities of the hosts. 

1 0 An additional, optional configuration of the peer to peer model would be a variation on 

the tree model of distribution (and authentication) by using a cluster model. The cluster would 
preferably have special attributes, where any given peer would reside in a cluster, and a specific 
topology of other peers would be established for each session (like a flat tree model), such that 
any change to that topology would affect some change in either authentication or distribution. 

1 5 For example, other peer devices would optionally and preferably be allowed to introduce new 
peer devices to the topology. This model could be effective in supporting various 
superdistribution models, for example where there are business rules that allow the redistribution 
of content from receivers of that content, under certain specified conditions. 

Such a model could optionally be specifically implemented according to the preferred 

20 embodiments of the present invention by enabling a local peer device, which has been 

authorized by an EMM for a specific service identifier, to send a new EMM for authorizing 
another host for that service identifier. If tighter control is desired, then another service identifier 
is most preferably required, which would then be reported back to the originating service 
provider (such as the broadcaster of Figure 3, for example), which is an example of a central 

25 authorization entity. The central authorization entity preferably at least coordinates the cluster, 
and more preferably continuously validates the cluster. 

Once the new service identifier is received, the provider could then add this service 
identifier to the list that becomes included in the ECM for decryption access. This avoids 
passing control of the new peer device from the interested peer device to a central authorizing 

30 authority, without involving any need to decrypt and re-encrypt at the local host level. 

Based on the previous model, local clusters of peer devices could optionally generate 
specific groups of requests to the central server which then arbitrates sessions to other clusters of 
such peer devices. 
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Alternatively or additionally, the local peer device is preferably able to receive anECM, 
use the control word to encrypt local content (through the security module such as the smart 
card) and then transmit such encrypted content to other peer devices. Alternatively, if the peer 
device is not able to perform encryption locally, or if the data is such that it does not require 
5 encryption, the generated control word could optionally still be used as a basis (or seed) for a 
hashed signature scheme, for example by using the smart card for generating the signature. 

However, the requirement for a certain level of computational ability of the peer device 
is a feature of these preferred embodiments. For example, if the peer devices are required to 
generate announcements, such as SPI messages, and/or EMMs, as well as to deliver content, a 
10 certain amount of buffer space is required to store all incoming CWs and SPI messages for 

decrypting. The generation of ECMs is most preferably kept at a central ECM generator, both 
for security reasons and to reduce the computational load on the peer devices. 

Optionally and more preferably, peer devices are distinguished with different levels of 
authorization and/or abilities. For example, some peer devices can view and write to all other 
i 5 devices, while some such devices can only view or write to certain devices, etc. Optionally, 
some peer devices may only be allowed to transmit content based upon the type of service 
identifier. 

According to other optional but preferred embodiments of the present invention, EMMs 
are delivered out of band (that is, separately from the content). For example, EMMs could 

20 optionally and preferably be delivered through encrypted (or open) e-mail messages. Using IETF 
standards such as Privacy Enhanced Mail (PEM) or MIME Object Security Services, or 
non-DETF PGP (Pretty Good Privacy). Unfortunately, delivery by e-mail messages again raises 
the issue of scalability. If the email message should be secured, then finding and using public 
keys is a problem. Such keys could optionally be cached locally or obtained from a public 

25 directory, although this may cause the processing overhead to become very high with a very 

slow distribution. Thus, preferably this mechanism is not used for key distribution, but only for 
EMM distribution, which could optionally be performed without encryption, such that only 
authentication signatures are preferably required, as a replacement for e-mail message 
invitations to multi-cast sessions. 



According to other optional embodiments of the present invention, particularly with 
regard to peer-to-peer distribution of content, content is authenticated by authenticating the 
source. For example, a signature or other secret information could optionally be added for this 
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purpose, such as an identifier for the source device (such as the source security module), and/or 
a public key signature. Preferably, however, the signature or other secret information is used as 
a seed to a simple hash function, which then enables the end user device to rapidly authenticate 
the source of the information. 

While the invention has been described with respect to a limited number of 
embodiments, it will be appreciated that many variations, modifications and other applications 
of the invention may be made. 
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WHAT IS CLAIMED IS: 

1 . A method for creating a secure transmission mechanism for a plurality of end 
user devices in a packet-based network, comprising: 

providing a plurality of packets; 

securing said plurality of packets according to security information to form secured 

packets; 

transmitting said security information to more than one end user device simultaneously 
through the packet-based network; and 

multi-casting said secured packets to the plurality of end user devices. 

2. The method of claim 1, wherein said plurality of packets contain broadcast data 
from a broadcasting event. 

3. The method of claims 1 or 2, wherein said packets are distributed through a 
second distribution channel, said second distribution channel being different from the 
packet-based network. 

4. The method of claim 3, wherein said second distribution channel is selected from 
the group consisting of satellite, cable, and wireless channels. 

5. The method of claims 1 or 2, wherein said packets are distributed through the 

packet-based network. 

6. The method of any of claims 1-5, wherein said security information includes 
control word information for key generation at each end user device. 

7. The method of claim 6, wherein an ECM (entitlement control message) is sent to 
said end user devices for said security information for said key generation, such that said ECM 
contains said control word information for said key generation. 
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8. The method of claim 7, wherein said ECM is multi-cast to said end user devices, 
and wherein an EMM (entitlement control message) is also transmitted to said end user devices, 
such that EMM information contained in said EMM is required for said end user device to 
access said ECM. 

9. The method of claim 8, wherein said EMM is transmitted to said end user devices 
by an out-of-band message, such that said EMM is not transmitted with said secured packets. 

10. The method of claim 9, wherein said out-of-band message is an e-mail (electronic 
mail) message. 

1 1 . The method of claims 8-10, wherein the packet-based network is an IP network 
and said ECM is transmitted through said IP network according to at least one of a multicast IP 
address and an IP port, such that said end user device is notified of said at least one of said 
multicast IP address and said IP port through an IP notification protocol. 

12. The method of any of claims 8-1 1, wherein said end user device filters at least 
one of said ECM and said EMM according to at least one characteristic selected from the group 
consisting of a characteristic of said end user device and a characteristic of information stored by 
said end user device. 

1 3 . The method of claim 12, wherein said end user device filters said ECM according 
to EMM information, such that only an ECM for which EMM information has been received is 
accessed by said end user device. 

14. The method of claim 13, wherein said ECM is contained in a packet, and an IP 
address for said packet is announced to said end user device, such that said end user device 
filters said ECM by listening to said IP address for receiving said packet if said end user device 
has received said EMM information. 

1 5 . The method of claim 12, wherein said end user device filters at least one of said 
ECM and said EMM according to whether said at least one of said ECM and said EMM is 
designated as unique, group or general. 
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1 6. The method of any of claims 8-15, wherein said EMM information includes a 
service identifier, and wherein said service identifier is related to a type of content of said 
secured packets. 

1 7. The method of claim 16, wherein said secured packets contain a plurality of 
different types of content, each type of content having a separate service identifier, such that 
differential access to said different types of content by said end user device is provided 
according to said service identifiers. 

1 8. The method of claims 16 or 17, wherein said service identifier corresponds to a 
plurality of ECMs. 

19. The method of any of claims 8-18, wherein said EMM information includes an 
identifier for determining access to said secured packets according to at least one characteristic 
selected from the group consisting of a characteristic of an end user device and a characteristic 
of information stored on said end user device. 

20. The method of claim 19, wherein said identifier is a blackout identifier for 
identifying an end user device blocked from accessing a content of said ECM. 

2 1 . The method of claim 20, wherein said blackout identifier corresponds to at least 
one characteristic stored in said end user device. 

22. The method of claim 21, wherein said at least one characteristic includes a 
geographical location of said end user device. 

23. The method of any of claims 8-22, wherein said ECM enables differential access 
to said secured packets by said end user device according to a plurality of identifiers transmitted 
in said EMM. 

24. The method of any of claims 8-23, wherein said end user device stores at least a 
content of at least one of said ECM and said EMM. 
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25. The method of claim 24, wherein said ECM has a limited key period, such that a 
new ECM is periodically received to access said plurality of packets. 

26. The method of claim 25, wherein a length of said key period is at least partially 
determined by a length of a session for receiving said secured packets by said end user device. 

27. The method of claim 26, wherein said length of said key period is less than said 
length of said session, such that at least one of a new ECM and a new EMM must be received 
repeatedly during said session. 

28. The method of claim 27, wherein said EMM has a limited authorization period, 
such that a new EMM is periodically received to access said plurality of packets. 

29. The method of any of claims 7-28, wherein at least a portion of said secured 
packets are accessible with said ECM only, without said EMM, as a preview of said secured 

packets. 

30. The method of any of claims 8-29, wherein said security information is 
transmitted according to a standard IP protocol. 

3 1 . The method of claim 30, wherein said packets are transmitted as part of a 
multi-cast session, and wherein an announcement for said session is transmitted according to a 
standard announcement protocol. 

32. The method of claims 30 or 3 1, wherein said standard IP protocol is IPSEC . 

33 . The method of claim 32, wherein said announcement includes information for 
relating each ECM to a service identifier contained in an EMM. 

34. The method of claim 33, wherein said announcement protocol is SDP (session 
description protocol). 
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35 . The method of claims 33 or 34, wherein said ECM is associated with at least a 
portion of a multi-cast session with said end user device, and wherein said association is 
transmitted in said secured packets as an attribute parameter. 

36. The method of claim 35, wherein said ECM is synchronized with said secured 
packets with an SPI (security parameters index) value of said secured packets. 

37. The method of claim 36, wherein a new key period is indicated by a change in 
said SPI value, such that a new ECM is required to access said secured packets. 

38. The method of any of claims 3 1-37, wherein announcement packets are 
encrypted. 

39. The method of any of claims 19-38, wherein said end user device is blocked from 
further access to said secured packets through revocation with at least one of an EMM and an 
ECM. 

40. The method of claim 39, wherein said revocation is for a specific end user device. 

4 1 . The method of claim 40, wherein said revocation is for a plurality of end user 
devices. 

42. The method of any of claims 39-41, wherein said revocation causes a new service 
identifier to be required for accessing a content of an ECM corresponding to said secured 
packets. 

43 . The method of any of claims 8-42, wherein said end user devices receive at least 
said secured packets from at least one peer end user device. 

44. The method of claim 43, wherein said at least one peer end user device generates 
at least one of said EMM and said ECM. 

45 . The method of claim 44, wherein said at least one peer end user device includes a 
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secure server for generating said least one of said EMM and said ECM. 

46. The method of claims 44 or 45, wherein said EMM generated by said at least one 
peer end user device is authenticated by a central authorization entity. 

47. The method of claims 44-46, wherein said EMM generated by said at least one 
peer end user device is mapped to a new ECM for accessing said secure packets by a central 
authorization entity. 

48. The method of any of claims 44-47, wherein said packets are transmitted as part 
of a multi-cast session, an announcement for said session is transmitted according to a standard 
announcement protocol, and said announcement includes at least an SPI (security parameters 
index) for relating each ECM to a service identifier contained in an EMM, such that said at least 
one peer end user device generates at least one of said announcement and said SPI. 

49. The method of any of claims 37-48, wherein said central authorization entity 
controls at least one of said ECM, said EMM, said announcement and said SPI. 

50. The method of any of claims 37-49, wherein at least one of said EMM and said 
ECM is generated by said central authorization entity. 

5 1 . The method of any of claims 37-50, wherein said end user devices are located in 
a cluster, and wherein each cluster is coordinated by said central authorization entity. 

52. The method of claim 51, wherein said cluster is continuously validated by said 
central authorization entity. 

53 . The method of any of claims 7-52, wherein a pay-per-view ECM contains 
purchasing information for purchasing access to said secured packets and wherein EMM 
information is not required to access said pay-per-view ECM. 

54. The method of any of claims 7-52, wherein an EMM contains a credit for 
purchasing access to said secured packets for pay-per-view content. 
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55. A secure transmission mechanism produced by the method of any of claims 1-54. 

56. A method for producing a conditional access (CA) system for use in a 
packet-switched environment (packet CA system) from a CA system for use in a broadcast 
environment (broadcast CA system), the method comprising: 

providing a broadcast CA system comprising at least one CA security characteristic; 

providing a packet-switched data transmission system including a security subsystem 
having a plurality of packet-switched security characteristics; and 

creating a mapping from the at least one CA security element to at least one of the 
plurality of packet-switched security elements, thereby producing a packet CA system. 

57. The method according to claim 56 and wherein the packet-switched data 
transmission system comprises an BP system. 

58. The method according to claim 57 and wherein the DP system comprises an 
IPSEC subsystem, and 

the EPSEC subsystem comprises the plurality of packet-switched security elements. 

59. The method according to any of claims 56-58 and wherein the broadcast CA 
system comprises an EMM / ECM based CA system. 

60. A conditional access (CA) system for use in a packet-switched environment 
(packet CA system) produced by the method of any of claims 56-59. 

61. A packet-switched conditional access (CA) system for use with an end-user 
playback device, the CA system comprising: 

a protected data receiver for receiving protected data protected with at least one key; 
an ECM packet receiver for receiving at least one ECM packet from a packet-switching 
network; and 

an ECM-based key generator for generating said at least one key from said at least one 
ECM packet. 
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62. The system according to claim 61 and also comprising: 

a key synchronizer for synchronizing said at least one key generated by the ECM-based 
key generator with a portion of said protected data protected with said at least one key generated 
by the ECM-based key generator. 



63. The system according to claim 62 and wherein the key synchronizer comprises: 
an ECM memory for storing a plurality of ECM packets; and 

an ECM packet chooser for choosing, from among the plurality of ECM packets stored 
by the ECM memory, an ECM packet corresponding to said portion of said protected data and 
sending said chosen ECM packet to said ECM-based key generator. 

64. The system according to any of claims 61-63 and wherein the ECM packet 
receiver comprises an EPSEC receiver for receiving the at least one ECM packet from the 
packet-switching network using an IPSEC protocol. 



65. A method for providing an entitlement control message (ECM) based conditional 
access (C A) system based on a packet-switching network comprising: 

receiving a plurality of ECMs via the packet-switching network; 
storing the plurality of received ECMs; and 

choosing, from among the plurality of stored ECMs, an ECM for providing 
access to CA-protected data. 

66. The method according to claim 65 and wherein the CA-protected data comprises 
encrypted data, and 

the method also comprises: 

utilizing the chosen ECM to decrypt the encrypted data. 

67. The method according to claim 66 and wherein the utilizing comprises: 
generating, from the ECM, a key for decrypting the encrypted data. 

68. The method according to claim 67 and wherein the generating comprises, at least 

in part: 

utilizing at least a portion of the ECM as an input to a one-way function; and 
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utilizing an output of the one-way function as at least a portion of the key. 

69. The method according to any of claims 65-68 and wherein the packet-switching 
network comprises an IP-based network. 

70. The method according to claim 69 and wherein the IP-based network comprises 
an DPSEC-based network. 

7 1 . The method according to claim 70 and wherein the plurality of ECMs are 
delivered using an BPSEC-based protocol. 

72. A method for creating a secure transmission mechanism for a plurality of end 
user devices in a packet-based network, comprising: 

encrypting a plurality of packets with a key to form encrypted packets, said key having 
associated key information for determining said key; 

multi-casting said associated key information to the plurality of end user devices through 
the packet-based network, thereby obviating the need to send said associated key information to 
each end user device individually; and 

multi-casting said encrypted packets to the plurality of end user devices to form the 
secure transmission mechanism. 

73 . The method of claim 72, wherein said associated key information is used by each 
end user device to generate said key. 

74. The method of claims 72 or 73, wherein said plurality of packets include 
streaming data from a broadcasting event. 

75. The method of claims 72 or 73, wherein said plurality of packets include data 
from a broadcasting event transmitted as a file. 

76. A method for creating a secure transmission mechanism for a plurality of end 
user devices in a packet-based network, comprising: 

multi-casting a plurality of secured packets and security information to the plurality of 
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end user devices, thereby obviating the need for a one-to-one transmission of said security 
information to each end user device individually and thereby forming the secure transmission 

mechanism. 

77. The method of claim 76, wherein said security information is sent through the 
packet-based network and said plurality of secured packets is sent through a separate channel to 
the plurality of end user devices. 

78. A system for multi-casting secure packets to a plurality of end user devices in a 
packet-based network, the secure packets being secured according to security information, 
comprising: 

(a) a broadcast headend connected to the plurality of end user devices at least 
through the packet-based network, said broadcast headend transmitting the security information 
to more than one of the plurality of end user devices, thereby obviating the need to send the 
security information to each end user device individually, and said broadcast headend 
transmitting the secure packets to the plurality of end user devices, wherein at least one of the 
security information and the secure packets is transmitted through the packet-based network. 

79. In a system for multi-casting secure packets to a plurality of end user devices in a 
packet -based network, the system comprising a broadcast headend connected to the plurality of 
end user devices at least through the packet-based network, providing a method for securing the 
packets, the method comprising: 

securing the secure packets according to security information; 

transmitting the security information by the broadcast headend to more than one end user 
device simultaneously according to a multi-casting protocol; and 

transmitting the secure packets by the broadcast headend to the plurality of end user 

devices; 

wherein at least one of the security information and the secure packets is transmitted through the 
packet-based network. 

80. The method of claim 79, wherein the secure packets are multi-cast in a session 
and the broadcast headend transmits an authorization message to the plurality of end user 
devices to enable the end user devices to access said session, such that the security information 
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includes said authorization message. 

81. A method for creating a secure transmission mechanism for a plurality of end 
user devices in an IP network, comprising: 

providing a plurality of data units for transport through the IP network; 
securing said plurality of data units according to security information to form secured 
data units; 

transmitting said security information to more than one end user device simultaneously 
through the IP network; and 

multi-casting said secured data units to the plurality of end user devices. 

82. A method for creating a secure transmission mechanism for a plurality of end 
user devices in a network having a characteristic of being at least one of packet-based and IP, 
comprising: 

providing a plurality of data units; 

securing said plurality of data units according to a control word to form secured data 
units, said control word being generated from security information; 

transmitting said security information to more than one end user device simultaneously 
through the network; 

multi-casting said data units to the plurality of end user devices; and 

generating said control word at each end user device with said security information 

83 . A method for creating a secure transmission mechanism for a plurality of end 
user devices in an IP network, comprising: 

providing a plurality of data units for transport through the IP network; 
securing said plurality of data units according to security information to form secured 
data units; 

transmitting said security information to more than one end user device simultaneously 
through the IP network; 

transmitting an announcement according to SDP (session description protocol) of IPSEC 
to said end user devices for indicating an association between said security information and said 
secured data units; and 

multi-casting said secured data units to the plurality of end user devices. 
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84. The method of claim 83, wherein said security information is related to a key for 
securing said secured data units, said key being changed according to a key period, a change of 
said key period being announced by an SPI (security parameters index) in a security information 
message according to ESP (IP encapsulating security payload) protocol. 

85. The method of claim 83, wherein said security information is related to a single 
key for securing said secured data units, and wherein said security information is transmitted 
according to a plurality of different ECMs, generated according to Simulcrypt protocols. 
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